It’s been just over a week since the SproutCore 1.5 RC1 was released, and we’ve been busy fixing many of the bugs reported by our tremendous community. To everyone who reported bugs: thank you! Your suggestions and real-world usage have been instrumental in ensuring production-ready quality as we approach the final release.

Here’s what’s new in RC2:

Bug Fixes

• A ton of bugfixes to TemplateView

• TemplateCollectionView now works with RecordArrays

• TemplateCollectionView is now much more efficient when the array it is representing changes

• Fixes a bug in the {{#each}} helper where the content was not updating after it changed

• Fixes a bug where {{bindAttr}} was not working when provided with a class attribute

• Explicitly documented the existence of the itemViewTemplate property in TemplateCollectionView

• Fixes a bug where computed properties were not being invalidated when the first property in the path of their dependent key changed

• Removed some trailing commas that were causing errors in Internet Explorer 7

• Fixes a bug where unit tests were failing on Internet Explorer 7

• Resolves an issue where text fields were not able to be activated on Android devices

• Removed an invalid warning when bindings were connected

Features

• Bindings now fire automatically when a property is changed via the debug console

• Substantial improvements to the inline documentation

• Updated QUnit to latest version

Enumerable Observers While we try our best not to introduce API changes once a release candidate is out, we did have to revisit how enumerable observers (a new 1.5 feature) were implemented. They are now restricted to arrays, and other enumerables that implement SC.Array, such as SC.ArrayController and SC.RecordArray.

This change was necessary since it allows us to prevent materializing records in record arrays, which could number in the thousands or tens of thousands. These observers have been renamed “array content observers” to indicate that they are restricted to ordered lists only. In the future, we will consider adding a similar API for collections where order is unimportant.

Note that in SproutCore, all ordered lists implement SC.Array, not just native Arrays. That means that you can use the new array observers with native Arrays, RecordArrays, SparseArrays, ArrayControllers and any other object that implements the SC.Array protocol.

More and more developers are adopting SproutCore every day, and the need for great documentation and tutorials just keeps growing. The Core Team is also making rapid progress on the new parts of SproutCore—the so-called sexy Edge. We’ve got the fantastic new SproutCore Guides to tackle the mainstream parts of SproutCore, and now, I’m aiming to tackle the new and exciting Edge parts. 

Every other week I’ll be posting what I’ll call Dispatches from the Edge. Each Dispatch will highlight a feature from the most recent release of SproutCore, explain how to use it, and wax on about why it’s so darn cool. Dispatches will also be where the team posts announcements about upcoming SproutCore-related events. Online, offline, we’ve pretty much got it covered :)

I’d like for this to be as helpful and interesting as possible, so if there’s something you want to know about, do let me know. Comment, tweet, email—I’ll be listening!

There’s been a lot going on in the world of template views lately, making it an optimal first topic for the Dispatch. One new feature stands out as being particularly exciting… so I’ll start there :)

When you create a template for a view, that template is really specifying what the display should look like all the time. Since that’s the case, when one of the properties of the view changes, it would be nice if the view would automatically redraw that section of its display to accomodate the changes in the data. The new template view does just that.

Let’s look at an example:

Dispatches from the Edge Part 1a from SproutCore on Vimeo.

Templates, however, do more than merely specify a set of attributes that get displayed on the screen. They often contain helpers like if, unless, or each to adequately describe how to display the state of the application. It would be nice if those helpers also could know automatically when they need to redraw themselves, so that developers need only specify once how the page should look, and then let the framework do the rest.

With the new template view, you can now use the normal Handlebars helpers (, , , and ), and if the properties they reference change, SproutCore will automatically update the DOM.

Let’s look at another example:

Dispatch from the Edge Part 1b from SproutCore on Vimeo.

The key point is that when we can make our templates declarative, the framework can in large part keep track of keeping the view up to date without any boilerplate code.

Announcements:

April’s looking busy for SproutCore meetups across the country:

• New York City: Wednesday, 4/20

• San Francisco: Tuesday, 4/26

• Boston (co-hosted with jQuery) : Thursday, 4/28

Core Team Member Yehuda Katz will also be speaking at the 4/14 Silicon Valley Ruby Meetup, as well as on Wednesday, 4/27 at Philadelphia’s Emerging Technologies for the Enterprise. 

Don’t see something up here that you think should be? Let us know!

We’re happy to announce the release of SproutCore 1.5 RC1, which includes significant improvements to TemplateView. Those improvements include:

• You can now use the normal Handlebars helpers ({{with}}, {{if}}, {{unless}}, and {{each}}) in your templates. If the properties they reference change, SproutCore will automatically update the DOM. For instance, if you use the {{#if}} helper with a true value, and the property later becomes falsy, SproutCore will automatically hide its contents.

• If you were using the {{#collection}} helper for simple iteration, you can now use the regular Handlebars {{#each}} helper, and it will automatically update the DOM as the underlying Enumerable changes.

• You can now use the normal Handlebars interpolation syntax ({{name}}), and SproutCore will automatically update the DOM when the underlying property changes; no need to use the {{bind}} helper anymore.

• These new features mean that you can use an existing Handlebars template and, through the power of bindings, have it automatically update as its content changes in other parts of the application.

• Handlebars helpers can now accept hash arguments. The syntax is: {{view id="my-view" class="my-class"}} You can use hash arguments in several important ways:

  • The view helper now takes id and class hash arguments. SproutCore will apply those attributes to the DOM element created for the view.

  • The {{view}} helper also accepts a classBinding attribute. When the value of the classBinding evaluates to true, SproutCore dasherizes the last part of the property name, and inserts the class. When it evaluates to false, SproutCore removes the class. For instance, if you say classBinding="content.isDone", SproutCore will insert and remove the class 'is-done' as the underlying property changes.

  • When you are creating a tag in markup, you can specify that certain attributes are bound. For instance, you could create a bound image tag: <img {{bindAttr src="url" alt="title"}}>. This will keep the src and alt attributes of the <img> tag in sync with the url and title properties on the current context object.

• Fixed a number of performance issues and memory leaks associated with using TemplateView and @each dependent keys.

We want to thank members of the SproutCore community for trying out our first version of TemplateView and providing excellent feedback. Your feedback helped nail down the thorniest problems in the new template syntax, and we think the result is pretty spectacular. Keep in mind that this release is not yet the final release of SproutCore 1.5, so please continue to provide feedback as you use the new functionality.Also, as the feature-set is pretty new, there are bound to be bugs. If you encounter a bug, please let us know right away so we can fix it!

As we approach our final release, we will prioritize bug fixes that correct regressions since the 1.4 series, as well as bug fixes for SC.TemplateView and Handlebars. If you find something amiss, please file an issue at our GitHub Issues page. Bugs with unit tests always get priority!

Release Schedule

An addition, as of this release, we are making some changes to how SproutCore manages its release schedule.  From now on, SproutCore is moving to regular six-week release cycles - just like Chrome. This means that you can expect the SproutCore 1.6 RC in six weeks (May 15).  At each release date, we will create a stable branch where further bug fixes will be added while master will always contain new tested but possibly unstable features.  This will allow us to continue polishing the final release while moving on to new features.

To goal for adopting short release cycles is to make it easier for you to adopt new features by ensuring that the framework regularly reaches a stable state.

Here’s a graphical representation of the next couple of release cycles:

You can find out the big-picture features that we are working on at any point in time, as well as features planned for future releases on our public Pivotal Tracker.

A big thanks to everyone who braved the rain and came out to last week’s San Francisco SproutCore Meetup! We had a great time chatting with all of you before and after; and hope you had your fill of pizza and learned a thing or two :)

If you missed the Meetup, fear not! Through some highly experimental webcamming, we’ve put together two talk recordings. It’s not quite as awesome as your very own neighborhood Meetup, but it’s a start.

Forgive the audio quality on Tom’s talk– it took us a little while to work out the kinks with our mic. We promise to be better next time :P

Check out Tom’s talk on the View Layer:

The View Layer- Talk by Tom Dale from SproutCore on Vimeo.

There’s also Yehuda’s introduction to SproutCore/Updates for the 1.5 beta: 

SproutCore 1.5 - Talk by Yehuda Katz from SproutCore on Vimeo.

Lastly, save the date: our next meetup is happening on Tuesday, 4/26! Keep an eye on the Meetup group for specific details.

See you there!

Yesterday, we released an updated version of the SproutCore 1.5 prerelease gem that contains our preliminary work on Amber and SC.TemplateView.

To us, Amber means significantly reducing the cognitive overhead of picking up SproutCore for the first time. A big part of that is leveraging technology that web developers already know: HTML and CSS. We’ve heard from developers in the past who said they loved SproutCore’s observers and bindings but were intimidated by the complexity of its view layer.

Part of easing developers into SproutCore means having the best documentation on the planet. Over the past month, contributors have done a kick-ass job of populating the SproutCore Guides site with up-to-date and easy-to-follow material. We wanted to provide a similar experience for SC.TemplateView, so we’ve written a hands-on guide to using it to build a simple (but still fully-featured) todo application.

You can find the guide at http://guides.sproutcore.com/html_based.html. It takes you through the process of initializing a new project, defining your models, designing your views, and then tying them all together with controllers and bindings. You can also check out the finished product at https://github.com/sproutcore/Todos-Example.

We think that describing the flow of data in your application, then allowing the framework to put the pieces together for you, leads to robust, maintainable applications. In fact, we think this declarative structure is the only way to build web applications that truly scale beyond simplistic demos like this one. We plan to create a second iteration of this app that really shows off how well the declarative model allows you to manage increasing complexity. But for now, we think you’ll be blown away at how features begin to emerge, almost like magic. By paying a small upfront cost, you begin to get functionality for free.

Because SproutCore does all of the heavy lifting, your app code remains small, and you don’t have to worry about introducing errors in your glue code. Other frameworks like to talk about their small size, and we think they are a good fit for simple apps, but their small size does you no good if you end up writing many of the features of SproutCore yourself.

While we’re not there yet, we are on track to have Amber ship at under 50k after gzip and minification. As examples like New Twitter show, apps of any sophistication end up dwarfing the frameworks upon which they are based precisely because they eventually have to implement their own abstractions. We’ve thought a lot about how client-side web applications can scale, and we think you’ll agree that SproutCore can ease growing pains as the client side gets ever more complex.

@tomdale & @wycats

**NOTE: **If you installed SproutCore 1.5.pre.4 yesterday, please make sure to update to SproutCore 1.5.pre.4.1 (gem install sproutcore –pre). There are some important bugfixes that are necessary in order for the tutorial.